Conversation
they do not appear to be used; we can recover them from `git` history if someone is relying on them (but they should be encouraged to use the more general, in-use code)
This fixes all the current compilation warnings. IMPORTANT: many `processeEvent` methods were retrieving _several_ more banks than the method actually needed; this commit removes several unnecessary `DataEvent.getBank` calls. In general: - variables that are obviously unused have been deleted - variables that may have been used for debugging have been commented out
Plot viewing should use the web front-end, not custom canvases and PNG output; we can allow webserver access to those who need it. Similar to the removal of `main` methods, if someone depends on `plot` methods, we may restore them from `git` history. We remove unused code so that we don't have to waste time maintaining it.
…ite` This makes calling the monitor classes a bit more general: - for each event, call `processEvent` - at the end, call `write` In some cases, two methods were called after event processing; additional methods are now just called by `write`. There are still variations in the methods' parameters, as well as their constructors.
All source code for detectors timelines is now in `src/` and compiles as a single module. We now have the following packages: - `org.jlab.clas.timeline`: main package for all timeline code - `org.jlab.clas.timeline.histograms`: reads HIPO data files and makes histograms - `org.jlab.clas.timeline.analysis`: analyzes histograms - `org.jlab.clas.timeline.fitter`: fits histograms; `analysis` classes call `fitter` classes - `org.jlab.clas.timeline.util`: miscellaneous common stuff
The current method to find Groovy JAR files at runtime fails in Arch Linux (and therefore in our container images), but has been working fine in production on `ifarm`. We should not need to add Groovy JARs to the class path; instead we can simply copy dependencies to the installation directory. I added the script `install.sh`, since the `mvn` command is slightly complicated. Now we no longer have to have `coatjava`'s JAR file and Groovy JAR files in the class path (in `environ.sh`); we just need `target` and `target/dependency`.
``` ana_2p2.java -> run_histograms.java run_detectors.groovy -> run_analysis.groovy ```
Seems that Apache has been wishy-washy regarding which modules are optionally included in `groovy-all` or not...
Using `coatjava`'s `run-groovy` will pull in that `coatjava` build's `CLASSPATH`, which may have conflicts with the `coatjava` JARs we use here in the timeline build. Since we set our own `CLASSPATH` here, use `groovy` as is, instead of `run-groovy`, for better control over the class path.
Using the maven-packaged `groovy` means there won't be a conflict between the user's system `groovy` version and the JAR files used by the `maven` build. Switching from `YamlSlurper` to `snakeyaml` should hopefully finally resolve the `snakeyaml` version conflict issue.
Now that we have our own `groovy` wrapper, `run-groovy-timeline.sh`, we can use it to set preferred `groovy` options.
- has not been used for quite a while - BST and BMT occupancies appear to be handled by `monitor2p2`
- has not been used in a while - many plots are handled elsewhere, namely by `monitor2p2`
``` cndCheckPlots.java -> CND.java central.java -> CTOF.java tof_monitor.java -> FTOFandDC.java ```
JeffersonLab/clas12-timeline#293 removes the explicit need for `groovy` and `coatjava` as external dependencies; the Maven build will just copy the necessary JAR files for these, so now the timeline code is much more standalone. RCDB remains as an external dependency. See the PR for reasoning and details. This should not be merged until we have actually deployed v3.
src/main/java/org/jlab/clas/timeline/histograms/FTOFandDC.java -> src/main/java/org/jlab/clas/timeline/histograms/DCandFTOF.java src/main/java/org/jlab/clas/timeline/histograms/monitor2p2GeV.java -> src/main/java/org/jlab/clas/timeline/histograms/GeneralMon.java
…Y groovy artifacts
JeffersonLab/clas12-timeline#293 removes the explicit need for `groovy` and `coatjava` as external dependencies; the Maven build will just copy the necessary JAR files for these, so now the timeline code is much more standalone. RCDB remains as an external dependency. See the PR for reasoning and details. This should not be merged until we have actually deployed v3.
JeffersonLab/clas12-timeline#293 removes the explicit need for `groovy` and `coatjava` as external dependencies; the Maven build will just copy the necessary JAR files for these, so now the timeline code is much more standalone. RCDB remains as an external dependency. See the PR for reasoning and details. This should not be merged until we have actually deployed v3.
|
@c-dilks ,This is amazing. I appreciate your work. |
|
I also like you throw away the 2p2. No one told me the truth, but I am really sure that it's from FX's naming about analyzing 2.2 GeV commissioning data. It doesn't make much sense to keep 2p2 in 2025. |
|
Hi @Sangbaek,
I assumed it was legacy; it hasn't been used by chefs or the CI tests and therefore it got removed, but we can recover it if needed. @dcarman, @raffaelladevita, @baltzell, @drewkenjo may know more about the history here (tagging them in case they want to comment).
Sounds good! Now that this massive PR is merged, it's a good time to get started on that.
Ah, I've been wondering about that name. Hopefully the new names are clearer. I couldn't think of a better name than |
JeffersonLab/clas12-timeline#293 removes the explicit need for `groovy` and `coatjava` as external dependencies; the Maven build will just copy the necessary JAR files for these, so now the timeline code is much more standalone. RCDB remains as an external dependency. See the PR for reasoning and details. This should not be merged until we have actually deployed v3.
This is a very large PR, I got carried away. The changes and reasoning are documented in the following description, organized by type of change:
Bug Fixes
Although this PR is supposed to be a refactor, the following bugs were fixed:
monitor2p2GeV.javacoatjavaand having agroovyversion that matches the POM version are no longer needed; the Maven build is now effectively standaloneRenames
are all part of the package
org.jlab.clas.timeline.histogramsrun_histograms.java(renamed fromana_2p2)"analysis" classes, and are all part of the package
org.jlab.clas.timeline.analysisrun_analysis.groovy(renamed fromrun_detectors.groovy)cndCheckPlots.java->CND.javacentral.java->CTOF.javamonitor2p2GeV.java->GeneralMon.javatof_monitor.java->DCandFTOF.javaprocessDirectory->processRun(cf. histogramming classes'processEvent)close->write(cf. histogramming classes'write)Removals
Note
Anything we have removed here can be recovered from
githistory, if someone needs itHistogramming Class Cleanup
processEventmethodsrun_histograms.java(renamed fromana_2p2.java) should only have to callprocessEventandwritefor each histogramming classcall
processEvent, at the end, callwriteadditional methods are now just called by
writeinsteadconstructors, but that's fine for now
mainandplotmethodsoutput; we can allow webserver access to those who need it.
Histogramming Class Removals
We have removed the following histogramming classes, none of which have been
used in quite a while:
occupancies.java, for BST and BMT occupancymonitor2p2deuterontarget.javamonitor2p2dst_mon.javasome time, since Daniel Carman said they are not needed.
dst_mon, beyond theFTOF ones; however, most of them are either unused or produced by something
else, namely
monitor2p2.Analysis Class Removals
groovyclassesare not needed.
Build Changes (Maven)
groovy-eclipse-compilerdetectorsandmonitoringmodules to a single moduleorg.jlab.clas.timeline: main package for all timeline codeorg.jlab.clas.timeline.histograms: reads HIPO data files and makes histogramsorg.jlab.clas.timeline.analysis: analyzes histogramsorg.jlab.clas.timeline.fitter: fits histograms;analysisclasses callfitterclassesorg.jlab.clas.timeline.util: miscellaneous common stuffLinux (and therefore in our container images), but has been working fine
in production on
ifarm. We should not need to add Groovy JARs to theclass path; instead we can simply copy dependencies to the installation
directory. I added the script
install.sh, since themvncommand isslightly complicated.
coatjava's JAR file and Groovy JAR filesin the class path (in
environ.sh); we just needtargetandtarget/dependency.coatjavaenvironment variables ($COATJAVA,$PATH, etc.)YamlSlurpertosnakeyaml, becauseof some dependency conflict
groovyrun-groovywith ourrun-groovy-timelines.shpom.xmlMiscellaneous
$RCDB_CONNECTIONStyle Changes
git diffimpossible to understand